Write a few shuffle algorithms for comparison.

I have found no formal statement that it is bias free,
but have tried to reason around it.  The algorithm should be
equivalent to generating more random decimals to decide
the shuffle order for elements with the same random number.
It should make no difference if the random decimals are generated
always and ignored, or when needed.

Speed: 1.2 s for 2^20 integers on my laptop.

The classical textbook shuffle.

Speed: 5 s for 2^20 integers on my laptop.

Quite a beautiful algorithm since the `gb_tree` has all
the functionality in itself.

Speed: 5 s for 2^20 integers on my laptop.

The same as the `gb_tree` above, but with a map.  Uses
the map key order instead of the general term order,
which works just fine.

Speed: 2 s for 2^20 integers on my laptop.

Suggested by Richard A. O'Keefe on ErlangForums as
"a random variant of Quicksort".  Shall we name it Quickshuffle?

Really fast. Uses random numbers efficiently by looking at
individual bits for the random split.  Has no overhead
for tagging.  Just creates intermediate lists as garbage.

This generator appears to be equivalent with shuffle1,
using a random number generator with 1 bit.

Speed: 0.8 s for 2^20 integers on my laptop.

The classical textbook shuffle.

Our standard `array` module here outperforms map, probably
because keys does not have to be stored, they are implicit.

Speed: 2 s for 2^20 integers on my laptop.

shuffle3 and shuffle4 have the theoretical limitation that
when the length of the list approaches the generator size,
it will take catastrophically much longer time to generate
a random number that has not been used.

There is no check for the list length being larger than
the generator size in which case it will be impossible
to generate unique random numbers for all list elements,
and the algorithm will simply keep on failing forever.
This is for now a theoretical problem since already for
a list length with log half the generator size
(e.g 2^28 with a generator size 2^56), my laptop
runs out of memory with a VM of about 30 GB.

shuffle1 and shuffle5 avoids that limitation.  shuffle1 by recursing
over the duplicates sublists so it is not affected much
by fairly long lists of duplicates, shuffle5 by using only
individual bits and ranges 2, 6, or 24.

The classical Fisher-Yates algorithm in shuffle2 and shuffle6
does not have this limitation, but generating random numbers
of unlimited length gets increasingly expensive, but should not be
any problem for 2 or even 4 times the generator length, that is
list lengths of well over 2^200, which is well over ridiculous.

* Use raw generator as bitstream.
* Optimize 3 and 4 elements permutation by rejection sampling
* Use `div` instead of `rem` for simpler reject-and-retry test.